Typically, an agreement between a party and a counter-party is manually defined by the parties. That is, one or both of the parties manually select a type of document that appropriately reflects the substance of the agreement (e.g., a particular type of contract) and/or agreement terms to be included in the document (e.g., contract clauses). The parties also manually generate and distribute the document for signature. Such a manual approach, however, has a number of disadvantages.
For example, the manual definition and generation of an agreement can be a time consuming and error-prone process, especially when a large number of potential document types and/or potential agreement terms can be associated with the agreement. Similarly, particular parties or localities may require different document types and/or agreement terms. As a result, the parties must carefully consider the substance of the agreement in order to select the appropriate document type and/or agreement terms.
Consider, for example, a transaction agreement associated with a number of different financial instruments (e.g., swaps and options) and financial products (e.g., equities and commodities). In this case, different combinations of financial instruments and financial products may call for different document types and/or agreement terms. Moreover, several different entities within a party (e.g., a bank's taxation department and legal department) may need to provide input to the process.
In addition, a single relationship between two parties may require that a number of different documents be generated, exchanged, and executed. For example, a master contract, a schedule to the master contract, a supporting document (e.g., a power of attorney), and a cover letter may all need to be generated. Manually generating and exchanging such sets of documents may be a difficult process, especially when different types of agreements require different combinations of documents.
It is known that some elements of agreement definition and generation may be automated. For example, U.S. Pat. No. 5,692,206 entitled “Method and Apparatus for Automating the Generation of a Legal Instrument” discloses a system that automates the generation of a legal document related to a negotiated agreement. Even this approach, however, does not address the potentially dynamic relationships that may exist between a party and a counter-party. For example, an agreement may be frequently amended to reflect new financial products or credit limits, and these amendments may be inter-related or retroactive. Such amendments are typically created as separate documents, making it difficult to ascertain the current status of an agreement, let alone the status of the agreement on a particular date in the past.
Moreover, known systems rely on hard-coded rules, programs, and architectures to facilitate definition of an agreement. Often, however, agreements are flexible (e.g., a new contract clause may suddenly become applicable to many different document types). In addition, the kinds of documents and contract terms that should be used for a particular agreement (or a way in which existing terms will be interpreted) can change over time. Because known systems are hard-coded, they may be unable to efficiently handle the fluid environments in which many agreements are made and changed. For example, a conventional database approach in which information is stored in pre-defined tables and columns may not be an effective, long-term approach to agreement definition and generation.